GitHub Workflow: Point-Based Budget System for External Development

This document outlines a structured GitHub workflow for managing the ABCloudz team using a monthly point budget system. The workflow ensures that work is properly scoped, prioritized, and kept within budgetary constraints for Phenom LLC.

Example Timeline (Gantt)

gantt dateFormat YYYY-MM-DD title Monthly Workflow Timeline (Approx. 60 Day Cycle) %% Removed excludes weekends as description uses calendar days section Planning & Approval (Days 1-21) Issue Creation (7d) :crit, 2025-05-01, 7d %% Day 1-7 Estimation (7d) :2025-05-08, 7d %% Day 8-14 Budget Allocation (7d) :2025-05-15, 7d %% Day 15-21 section Development & Testing (Days 22-55) Development & Bug Fixing (30d) :active, 2025-05-22, 30d %% Days 22-51 Beta Testing (11d) :2025-06-14, 11d %% Days 45-55 section Invoicing & Payment (Days 56-60) Submit Invoice (1d) :2025-06-25, 1d %% Day 56 Verify & Process Payment (4d) :2025-06-26, 4d %% Days 57-60 section Review & Closure (Day 60+) Retrospective (1d) :2025-06-30, 1d %% Day 60 (Starts after payment verification) %% Production Deployment happens separately based on release schedule

Overview

Detailed Workflow

1. Repository Setup

1.1 Repository Structure

1.2 Issue Templates

Create specialized templates for:

Each template should include fields for:

2. Monthly Planning Cycle

2.1 Issue Creation Phase (Days 1-7)

2.2 Estimation Phase (Days 8-14)

2.3 Budget Allocation Phase (Days 15-21)

2.4 Development Phase (Days 22 - Next Month Day 21)

3. Issue Workflow States

  1. Needs Estimation - New issue created, awaiting point estimation.
  2. Estimated - Points assigned, awaiting approval.
  3. Approved for Development - Selected for current budget cycle.
  4. In Progress - Currently being worked on.
  5. In Review - Pull request submitted, awaiting code review.
  6. Beta Testing - Feature branch deployed to staging/testing environment after PR approval.
  7. Beta Approved - Testing passed, PR ready to be merged.
  8. Merged / Ready for Invoice - PR merged into main/develop branch. Issue is now eligible for invoicing.
  9. Invoiced - Included in a submitted invoice.
  10. Paid - Payment processed after verifying merge and invoice details.
  11. (Optional) Production Deployed - Code deployed to production (tracked separately from invoicing).

4. Point Estimation Guidelines

4.1 Fibonacci Point Scale

The team will use the Fibonacci sequence for point estimation (1, 2, 3, 5, 8, 13, 21): (See: What Are Story Points? by Mike Cohn)

The ABCloudz team needs to assess the expected cost of a typical issue estimated at a level of effort of 3 points.

4.2 Standardized Pricing

To simplify budget planning and payment processing, a standardized price is established based on the value of a single point. Context: This model combines standard Agile estimation (using story points for relative effort) with a fixed-price-per-unit billing approach. While not a universally standardized methodology with a single governing document, it aims to provide budget predictability by tying cost directly to estimated work units. Its success relies on consistent estimation practices and a clear contractual agreement between Phenom and ABCloudz. This approach relates to broader concepts discussed in Agile contracting and value-based pricing models.

References on Agile Estimation & Contracting:

4.3 Monthly Budget Calculation

For a monthly budget, determine the total number of points Phenom wants to allocate:

Note: Issues estimated at 21 points or higher should generally be broken down into smaller, more manageable issues.

4.4 Handling Bug Fixes for Prior Work

Bugs identified that are directly attributable to features or code previously developed and invoiced by ABCloudz should generally be addressed by ABCloudz without assigning new story points or incurring additional costs, provided they are reported within an agreed-upon warranty period (e.g., 30 days post-merge). These fixes are considered part of ensuring the quality of the original delivery.

New, unrelated bugs, or bugs found outside the warranty period for the original work, should be created as standard issues and follow the normal estimation, approval, and billing process outlined in this document.

5. Monthly Budget Management

5.1 Budget Tracking

5.2 Budget Adjustment Process

If changes are needed mid-cycle:

  1. Phenom creates an issue labeled budget-adjustment
  2. The adjustment is discussed and approved by stakeholders
  3. The budget tracking information is updated
  4. Additional issues may be approved or postponed

6. GitHub Automation and Integration

6.2 Reporting Automation

Create a weekly report with:

7. Production Deployment and Payment Process

7.1 Feature Branch Testing and Production Approval

This process, where features are tested in isolation on their own branches before being merged into the main codebase, aligns with industry best practices like GitHub Flow and Continuous Integration/Continuous Deployment (CI/CD). This approach helps ensure the stability of the main codebase and allows for thorough testing without impacting other development work.

  1. When development on an issue is complete, the developer creates a Pull Request (PR) targeting the main or develop branch (as per project setup). The issue is marked with the in-review label.
  2. A Phenom representative reviews the code changes in the PR.
  3. Once the PR is approved, the feature branch itself is deployed to a staging or testing environment. The issue is marked with the in-beta label and moved to the "Beta Testing" column.
  4. Beta testers verify the changes on the feature branch meet the acceptance criteria. Test results are documented in the issue comments.
  5. If beta testing is approved, the issue gets the beta-approved label. The PR can then be merged into the main/develop branch.
  6. If beta testing fails, the issue gets the beta-rejected label and is returned to the "In Progress" state with feedback for the developer.
  7. Code that has passed beta testing and has its PR successfully merged into the main/develop branch is eligible for invoicing.

References:

7.2 Invoicing and Production Deployment

7.3 Payment Processing

7.3 Review and Retrospective

7.4 Carry-over Process

For incomplete issues:

  1. Assess remaining work and adjust points if needed
  2. Decide whether to prioritize in next cycle
  3. If carried over, add carry-over label
  4. Include in next cycle's budget calculation

8. Example GitHub Project Board

Backlog Needs Estimation Estimated Approved In Progress In Review Beta Testing Beta Approved Merged / Ready for Invoice Invoiced Paid (Optional) Production Deployed
Future issues Awaiting points Has points, awaiting approval Approved within budget Currently being worked on PR submitted, awaiting review Feature branch deployed for testing Testing passed, ready to merge PR merged, eligible for invoice Included in invoice Payment processed Code live in production

9. Example Monthly Timeline

Note on Cycle Length: While the end-to-end process for a single batch of work (from creation to payment) spans approximately 60 days as shown above, the workflow operates on overlapping monthly cycles. Planning for the next month begins on Day 1 while the previous month's development is still in progress.

Implementation Instructions

Setting Up This Workflow

  1. Create Labels:

  2. Configure Project Board:

  3. Create Issue Templates:

  4. Set Up Milestone Template:

  5. Document Process:

Workflow Diagrams

Role-Based Workflow (Swimlane)

sequenceDiagram participant PO as "Product Owner (Matt Stevens)" participant PM as "Phenom Management" participant ABC as "ABCloudz Developers" participant Beta as "Phenom Beta-Testers" Note over PO, ABC: Monthly Planning Cycle (Days 1-21) PO->>PO: Define Requirements & Create Issues (Days 1-7) PO->>ABC: Issues Ready for Estimation (`needs-estimation`) ABC->>ABC: Review & Estimate Issues (Days 8-14) ABC->>PM: Issues Estimated (`estimated`) PM->>PM: Review Estimated Issues PM->>PO: Discuss Prioritization & Budget PO->>PM: Confirm Priorities PM->>PM: Allocate Budget & Select Issues (Days 15-21) PM->>ABC: Issues Approved for Development (`approved`, Milestone assigned) Note over ABC, Beta: Development & Testing Cycle (Days 22 - ~Day 55) ABC->>ABC: Develop Approved Issues (`in-progress`) ABC->>PM: Submit Pull Request (`in-review`) PM->>PM: Review PR Code alt PR Approved PM->>ABC: PR Approved ABC->>ABC: Deploy Feature Branch to Staging (CI/CD Action) ABC->>Beta: Ready for Beta Testing (`in-beta`) Beta->>Beta: Perform Beta Testing alt Beta Testing Passed Beta->>PM: Report Test Results (`beta-approved`) PM->>ABC: Merge Beta-Approved PR (`merged-ready-for-invoice`) (CI/CD Action) else Beta Testing Failed Beta->>PM: Report Test Results (`beta-rejected`) PM->>ABC: Feedback for Rework (Return to `in-progress`) end else PR Needs Changes PM->>ABC: Request Changes (Return to `in-progress`) end Note over ABC, PM: Invoicing & Payment Cycle (~Days 56-60) ABC->>PM: Submit Invoice for Merged Issues (`invoiced`) PM->>PM: Verify Invoice against Merged PRs PM->>PM: Process Payment PM->>ABC: Payment Sent (`payment-processed`) PM->>PM: Close Paid Issues / Milestone Note over PO, PM: End of Cycle Review (Day 60+) PO->>PO: Review Cycle Outcomes PM->>PM: Hold Retrospective with PO & ABC PO->>PM: Discuss Carry-over Issues & Next Cycle Planning Note right of Beta: (Production Deployment occurs separately based on release schedule)

Conclusion

This workflow provides a structured approach for Phenom LLC to manage the ABCloudz team within budget constraints while maintaining flexibility, transparency, and accountability. By following this process, Phenom can effectively track work, manage costs, and ensure consistent value delivery from ABCloudz.